-
Notifications
You must be signed in to change notification settings - Fork 5
OSAL Firmware update implementation for EFR32 Wi-SUN #30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: osal
Are you sure you want to change the base?
Conversation
9ed24fd
to
92d1715
Compare
Tested Linux and EFR32 version:
|
FYI Critical memory leak is solved in 3bba235 It's a general issue for all platforms, since it's in csmp_firmwareMgmt.c that is a not platform specific library source. |
…ge is stored into the flash
…l slot copy operation
…ign with the implementation
1fbefd0
to
bd77d6f
Compare
Updated PR to be aligned with osal HEAD:
Test results:
|
@manojnacsl As we discussed, I describe the improvement ideas. In this case we don't need osal_write_firmware, that writes data to the file from offset 0. I note that, more gecko bootloader API calls are moved to the appropriate TLV handler, they have been removed from OSAL. If we can operates only with OSAL APIs in the TLV handlers, we can have only one TLV implementation, and the abstraction can be solved in OSAL only, in this case we can remove the TLV abstraction later. To compare extended OSAL APIs with the current head, you can use this commit as reference (diff osal.h) |
The PR is based on osal_fw_rw_api branch and it consist 3 well separated topics:
1. Fixed build issues for all platforms: linux, FeeRTOS, efr32_wisun
2. Refactor OSAL APIs and introduce new APIs.
Slot header and related definitions are moved to OSAL
osal_read_firmware() and osal_write_firmware() are refactored: The original APIs were designed to write and read the entire firmware image to the storage, on linux, into a file. For EFR32 platform we need to use gecko bootloader storage to store the images and the image cannot be stored in the RAM. The new osal_read_firmware_slothdr() and osal_write_firmware_slothdr() can be used to store the header only. For EFR32 NVM3 (non volatile memory section) is used to store the headers
osal_write_storage() API is introduced as a portable interface to implement write storage operation for storing data chunks in the image block POST request. For linux it's a simple memcpy, for EFR32, Gecko bootloader write storage is used.
osal_erase_storage() API is implemented to erase the particular storage slot. Gecko Bootloader requires erase operation before the write operations to store a new image to the "upload" slot.
osal_deploy_and_reboot_firmware() API is implemented for having portable bootloader API calls. Gecko Bootloader requires "verify image", "set image to boatload" and "reboot and install" calls for EFR32. The bootable image slot should contain the GBL (Gecko Bootloader) file content.
osal_copy_firmware_slot() API is introduced for having copy operation. For "backup" request, we need to copy "upload" storage slot to the "backup" storage slot, that is not a simple memcpy operation.
3. Implement APIs and TLVs for EFR32, refactor existing platform TLVs.
Initialise 2 Gecko bootloader storage slot with 512KB size: Upload, Backup storage slots. Run image storage slot is the internal application flash in EFR32 SoCs, therefore it is not implemented as available storage slot.
All the APIs are implemented for all platforms. If the platform doesn't support the particular API, an empty implementation is provided.
Implemented EFR32 TLVs: in image block post request, we need to remove the Csmp header from the first chunk, because it can't be stored in the bootloader slot. In the TLV, the bootloader slot offset is calculated and managed separately from firmware image offset.
Implemented OSAL APIs for EFR32: Gecko Bootloader and NVM3 API are integrated. NVM3 is used for storing storage header for all slots: Run, Upload, Backup.
Csmp header structure is refactored: "image" allocation is removed from the structure definition (only for EFR32)
Improvement ideas
emulate storage slot implementation for linux: creating a file per storage with 1MB size, that is filled with dummy data. Using fseek API, the chunks cane be stored directly in to the file, image allocations is not required. An other benefit is matching with other platforms
remove tlvs port sources. If the OSAL API-s are well-defined, and can be used in the TLV handlers, portable TLV handlers are not required anymore (The same recommendation in osal_fw_rw_api PR)
remove code duplications, move platform specific and common source to OSAL: csmp_info.h and csmpinfo.h are the same. In this PR the Csmp header definitions is moved into OSAL too. Library sources can use the OSAL API.